ES6标准出炉之前,一个幽灵,回调的幽灵,游荡在JavaScript世界。
正所谓:
世界本没有回调,写的人多了,也就有了
})})})})})
。
Promise
的兴起,是因为异步方法调用中,往往会出现回调函数一环扣一环的情况。这种情况导致了回调金字塔问题的出现。不仅代码写起来费劲又不美观,而且问题复杂的时候,阅读代码的人也难以理解。
举例如下:
db.save(data, function(data){
// do something...
db.save(data1, function(data){
// do something...
db.save(data2, function(data){
// do something...
done(data3); // 返回数据
})
});
});
假设有一个数据库保存操作,一次请求需要在三个表中保存三次数据。那么我们的代码就跟上面的代码相似了。这时候假设在第二个db.save
出了问题怎么办?基于这个考虑,我们又需要在每一层回调中使用类似try...catch
这样的逻辑。这个就是万恶的来源,也是node刚开始广为诟病的一点。
另外一个缺点就是,假设我们的三次保存之间并没有前后依赖关系,我们仍然需要等待前面的函数执行完毕, 才能执行下一步,而无法三个保存并行,之后返回一个三个保存过后需要的结果。(或者说实现起来需要技巧)
不幸的是,在我刚开始接触node的时候,我写了大量这样的hell。
作为一个有时还动下脑子的程序员,我尝试了朴灵大人的eventproxy。后来因为还是写前端代码多一些,我接触了ES6,发现了一个解决回调深渊的利器Promise
。
其实早在ES6的Promise
之前,Q
,when.js
,bluebird
等等库早就根据Promise
标准(参考Promise/A+)造出了自己的promise
轮子。
(看过一篇文章,我觉得很有道理。里面说,不要扩展内置的原生对象。这种做法是不能面向未来的。所以这里有一个提示:使用扩展原生Promise
的库时,需要谨慎。)
这里仅讨论原生的Promise
。
ES6 Promise
Promise对象状态
在详解Promise
之前,先来点理论:
Promise/A+
规范, 规定Promise对象是一个有限状态机。它三个状态:
pending
(执行中)fulfilled
(成功)reject
(拒绝)
其中pending为初始状态,fulfilled和rejected为结束状态(结束状态表示promise的生命周期已结束)。
状态转换关系为:
pending->fulfilled,pending->rejected。
随着状态的转换将触发各种事件(如执行成功事件、执行失败事件等)。
Promise形式
Promise的长相就像这样子:
var promise = new Promise(function func(resolve, reject){
// do somthing, maybe async
if (success){
return resolve(data);
} else {
return reject(data);
}
});
promise.then(function(data){
// do something... e.g
console.log(data);
}, function(err){
// deal the err.
})
这里的变量promise
是Promise
这个对象的实例。
promise对象在创建的时候会执行func
函数中的逻辑。
逻辑处理完毕并且没有错误时,resolve
这个回调会将值传递到一个特殊的地方。这个特殊的地方在哪呢?就是下面代码中的then
,我们使用then
中的回调函数来处理resolve后的结果。比如上面的代码中,我们将值简单的输出到控制台。如果有错误,则reject
到then
的第二个回调函数中,对错误进行处理。
配合上面的有限状态机的理论,我们知道在Promise
构造函数中执行回调函数代码时,状态为pending
,resolve
之后状态为fulfilled
,reject
之后状态为reject
Promise数据流动
以上是promise的第一次数据流动情况。
比较funny的是,promise的then
方法依然能够返回一个Promise
对象,这样我们就又能用下一个then
来做一样的处理。
第一个then
中的两个回调函数决定第一个then
返回的是一个什么样的Promise
对象。
假设第一个
then
的第一个回调没有返回一个Promise
对象,那么第二个then
的调用者还是原来的Promise对象,只不过其resolve
的值变成了第一个then
中第一个回调函数的返回值。假设第一个
then
的第一个回调函数返回了一个Promise
对象,那么第二个then
的调用者变成了这个新的Promise
对象,第二个then
等待这个新的Promise
对象resolve
或者reject
之后执行回调。
话虽然饶了一点,但是我自我感觉说的还是很清楚的呢。哈哈~
如果任意地方遇到了错误,则错误之后交给遇到的第一个带第二个回调函数的then
的第二个回调函数来处理。可以理解为错误一直向后reject
, 直到被处理为止。
另外,Promise
对象还有一个方法catch
,这个方法接受一个回调函数来处理错误。即:
promise.catch(function(err){
// deal the err.
})
假设对错误的处理是相似的,这个方法可以对错误进行集中统一处理。所以其他的then
方法就不需要第二个回调啦~
控制并发的Promise
Promise有一个"静态方法"——Promise.all
(注意并非是promise.prototype
), 这个方法接受一个元素是Promise对象的数组。
这个方法也返回一个Promise
对象,如果数组中所有的Promise
对象都resolve了,那么这些resolve的值将作为一个数组作为Promise.all
这个方法的返回值的(Promise
对象)的resolve值,之后可以被then
方法处理。如果数组中任意的Promise
被reject
,那么该reject
的值就是Promise.all
方法的返回值的reject
值.
很op的一点是:
then方法的第一个回调函数接收的resolve值(如上所述,是一个数组)的顺序和Promise.all中参数数组的顺序一致,而不是按时间顺序排序。
还有一个和Promise.all
相类似的方法Promise.race
,它同样接收一个数组,只不过它只接受第一个被resolve的值。
将其他对象变为Promise对象
Promise.resovle
方法,可以将不是Promise对象作为参数,返回一个Promise
对象。
有两种情形:
假设传入的参数没有一个
.then
方法,那么这个返回的Promise
对象变成了resolve状态,其resolve的值就是这个对象本身。假设传入的参数带有一个
then
方法(称为thenable
对象), 那么将这个对象的类型变为Promise
,其then
方法变成Promise.prototype.then
方法。
Promise是解决异步的方案吗?
最后说一点很重要的事:Promise
的作用是解决回调金字塔的问题,对于控制异步流程实际上没有起到很大的作用。真正使用Promise
对异步流程进行控制,我们还要借助ES6 generator
函数。(例如Tj大神的co
库的实现)。
然而ES7将有一个更加牛逼的解决方案:async/await
,这个方案类似于co
,但是加了原生支持。拭目以待吧。
文档
以上。一点微小的见解,谢谢大家。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。